This application relates generally to a method for concurrent communication of dynamic vehicle telemetry between a transceiver connected to a vehicle data port and a plurality of computing devices, such as a desktop computer or hand-held device, and in particular to a method of concurrently providing motor vehicle data to a plurality of users using a heterogeneous group of user devices, while allowing each user to customize the data displayed on the user's device.
Since 1996, every passenger car and light-duty truck sold in the United States has had a computer diagnostic port, called an OBD-II port or an SAE-J1962 port. This diagnostic port permits a mechanic or other user to connect to the vehicle and retrieve vehicle telemetry, that is, data about the vehicle, including engine, fuel system, brake system, and other data. Software has been developed to permit mechanics and automobile enthusiasts to develop graphical programs for displaying the telemetry data on a computer display.
Traditionally, vehicle data ports and diagnostic systems have been designed around a model of a single external device (or “scan tool”) connected to a vehicle at one time. If a dashboard display device is already connected to the vehicle data port and a user wanted to plug in a separate scan tool, the user either had to unplug the dashboard display device, or somehow split the wires so that a second device can be connected. In fact, many companies currently sell vehicle data port splitters (or “Y-cables”).
In most cases, these types of arrangements are constructed so that multiple devices are physically connected to (or in electrical communication with) the vehicle data port, but typically only one device is actively communicating with the vehicle at any given time, while one or more other devices are in a monitor-only mode, without active bidirectional communication directly with the vehicle. This way, the vehicle maintains bidirectional communication with only a single device at a time. Often, that connected device has no knowledge that other external devices are also monitoring communications from the vehicle.
Using a splitter or “Y-cable” with more than one device concurrently communicating with vehicles today causes a number of problems. It is widely assumed that only one device will be communicating with the vehicle at once, and some vehicles even enforce this by only responding to data requests from a single address. In fact, newer vehicle data protocols have standardized on this practice by assigning external equipment only a single allowable address range. If more than one device concurrently communicates with the vehicle, these protocols cause addressing conflicts, data collisions, timing violations and other kinds of related data acquisition problems.
In the past, the multiple connected device usage has been mostly limited to the scan tool designers who occasionally want to connect a second device using a “Y-cable” to monitor the requests they transmit to verify conformance or to monitor and debug the scan tool communications. However, contrary to much of the prevailing wisdom in this area, the ability to have concurrent users all communicating with the same vehicle has definite advantages. Thus, development of such a system while staying compliant with existing vehicle protocols, which were typically not designed with multiple concurrent connections in mind, could be very useful.